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@ Objektmodell und Verfahren zum Erfassen von Informationen 

@ Objektmodell zum Erfassen von Informationen, die 
produktinnovationsbezogene Daten betreffen, mit einer 
Produktideeschnittstelle zum Erfassen einer idee fur ein 
Produkt in einem Produktideeobjekt und einer Gestal- 
tungsalternativenschnittstelle zum Erfassen einer Vielzahl 
von Gestaltungsalternativen fur das Produkt in einer Viel- 
zahl von jeweijigen Gestaltungsalternative-Objekten. 
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Beschreibung 

[0001] Die vorliegende Erfindung betrifft allgemein die 
Infoniiationsverwaltung und im besonderen ein System 
bzw. Objektmodeil und ein Verfahren zum Erfassen und 
Speichern von und Zugreifen auf Informationen, die wah- 
rend der Innovation eines Produktes in einer bestandigen 
und werkzeugneutralen Form verwendet werden. 
[0002] Produktentwicklung wird heutzutage von compu- 
terbasierten Anwendungen unterstiitzt, u. a. durch Textver- 
arbeitungs- und Grafikwerkzeuge, Abwicklungswerkzeuge 
(Temunkoordiniemng/Abiaufsteuerung) und Produktdaten- 
verwaltungswerkzeuge. Der typische Produktentwicklungs- 
zyklus beginnt mit einer Idee fur ein Produkt oder einer Ver- 
besserung fur ein Produkt, das ein Bedurfnis in der Industrie 
betrifft oder eme Losung fur ein Problem darstellL Ausge- 
hend von der Produktidee konnen unterschiedliche Ent- 
wurfe (Altemativgestaltungen) untersucht werden und 
schlieBlich wird ein Entwurf bzw. eine Gestaltung ausge- 
wahlt, entwickelt/umgesetzt und implementiert. Wahrend 
der Anfangsphasen des Produktentwicklungszyklus werden 
Textverarbeitungs-, Grahk- und Ablaufwerkzeuge oft ver- 
wendet, urn Informationen wie Marketinganalysen, projek- 
tierte Entwicklungsablaufe und Beschreibungen und Be- 
griindungen, die bestimmten ausgewahlten Entwurfen zu- 
grunde liegen, zu erfassen. Wahrend der Entwurfs- bzw. Ge- 
staltungsphase werden die Gestaltung betrefTende Informa- 
tionen, wie die Gestaltungsspezifikationen und 3-D-Modell- 
daten, ublicherweise unter Verwendung eines CAD-Werk- 
zeugs erfaBt. Wahrend der Herstel lung des Produkts werden 
Informationen zur Teiieverfolgung ublicherweise unter Ver- 
wendung eines PDM-Werkzeugs (PDM: Product Data Ma- 
nagement, Produktdatenverwaltung) erfaBt Zur Veran- 
schaulichung soli davon ausgegangen werden, daB ein Ent- 
wickler/Gestalter eine Idee fur ein neues Produkt hat Der 
Entwickler ist sich dabei mehrerer Anforderungen bewuBt, 
die das Produkt erfullen muB und hat einige Losungsideen. 
Der Entwickler muB mehrere unterschiedliche Werkzeuge 
benutzen, urn Darstellungen unterschiedlicher TeiLe der Lo- 
sung zu crzcugcn. Bcispiclswcisc bcnutzt der Entwickler 
Microsoft Excel zum Erzeugen einer Kostenanalyse, Corel 
zur graphischen Darstellung, SolidDesigner fiir ein erstes 
Raumbudget und Work-Manager von CoCreate zur Erzeu- 
gung einer crstcn Funktionsorganisation. 
[0003] Wahrend es klar ist, daB unterschiedliche compu- 
terbasierte Werkzeuge die Erfassung von Informationen und 
das Verfolgen des Forlschrilts eines Produktes unlerstuton 
weist der Stand der Technik einige Nachteile auf. Erstens 
existiert derzeit kein Werkzeug, das konkret zur Erfassung 
und Verfolgung von Ideen und Entscheidungen zu diesen 
Ideen wahrend der Anfangsphasen der Produklenlwickl ung 
dient. Die Untersuchung von Ideen ist haufig eine Situation 
in der viel Empirie bzw. Regula falsi (trial and error) betrie- 
ben wird. Urn eine derartige Untersuchung erfolgreich ver- 
folgen zu konnen, ist es notwendig, viele nur teilweise voll- 
standigen Informationsstrukturen, die Entscheidungen, ei- 
nen Untersuchungsweg weiterzuverfolgen oder aufzugeben 
und die Erklarungen/Begriindungen hinter diesen Entschei- 
dungen zu erfassen. Es ist auch nutzlich, die Absicht bzw. 
den Zweck einer besUmmten Losungsalternative zu erfas- 
sen. Im Stand der Technik existiert kein einzelnes Werkzeug 
zum Erfassen und Verfolgen derartiger wichtiger Informa- 
tionen einschiieBlich der Beweggriinde und Ziele eines Ent- 
wurfs, Fragen, Ideen und Antworten, die wahrend der Un- 
tersuchung des Entwurfs gestellt werden, und der gleichen 
Informationen bezuglich ebenfalls untersuchter Gestal- 
tungsalternativen. Selbst wenn einige der Informationen un- 
ter Verwendung eines oder mehrerer unterschiedlicher 



Werkzeuge erfaBt wird, weil die Informationen nicht inte- 
gnert oder einfach zuganglich sind, auBer das bestimmte 
Werkzeug, das zur Erfassung der Informationen benutzt 
wurde, wird verwendet, werden des weiteren viele der an- 
5 fanglichen Gestaltungsabsichten und Erklarungen/Beweg- 
griinde von Gestaltungsentscheidungen sowie die unter- 
suchten Gestaltungsaltemativen ublicherweise nicht effek- 
tiv erfaBt oder gehen mit Fortschreiten des Entwickluneszy- 
klus des Produkts verloren. 
10 [0004] Zusatzlich werden im Stand der Technik alleent- 
wurfsbezogenen Informationen, die unter Verwendung eines 
bestimmten computerbasierten Werkzeugs erfaBt werden, 
ublicherweise nur uber das zur Erzeugung der Daten ver- 
wendete Werkzeug gespeichert, verwaltet und abgerufen. Es 
15 gibt mehrere Griinde, warum die Moglichkeit, auf Daten, 
die von einem Werkzeug erzeugt wurden, unter Verwendung 
anderer Werkzeuge zugreifen zu konnen, vorteilhaft ware 
Insbesondere konnen die Informationen, die unter Verwen- 
dung eines Werkzeugs erfaBt wurden, fur unterschiedliche 
20 Menschen von unterschiedlichen Einheiten, die unterschied- 
liche Aufgaben wahmehmen, interessant sein. So konnen 
beispielsweise Informationen, die wahrend des Entwurfs 
bzw. der Gestaltung eines Produkts erfaBt wurden, nicht nur 
fur die Gestaitungsingenieure, sondern auch fur die Ilerstel- 
25 lungs- und Testingenieure, Fuhrungskrafte im Produktent- 
wicklungsprozeB, Wartungstechniker, Marketing- und Ver- 
kaufspersonal, Disponenten, Personal in der Auftragsverar- 
beitung, Website-Entwickler und-verwalter, Kunden, Zulie- 
ferer usw. nutzlich sein. 
30 [0005] Es existiert demnach ein Bedurfnis, Informationen 
zur Produktentwicklung, nachfolgend als "Innovationsinfor- 
mationen" bezeichnet, einschiieBlich Produktideen, Gestal- 
tungsaltemativen, Fragen und Antworten, die wahrend des 
Innovationsprozesses untersucht wurden, Entwurfsentschei- 
35 dungen usw. zu erfassen, zu speichern und abzurufen. Es be- 
steht auch ein Bedurfnis, die Innovationsinformation in ei- 
ner werkzeugneutralen Form zu erfassen, die jedem Werk- 
zeug einen Zugriff auf die (und ggf. auch eine Modification 
der) Innovauonsinformauonen gestattet. Ein derartiges 
40 Werkzeug wiirdc die Verfolgung der graducUcn Entwick- 
lung vom Entwurf und Entscheidungen uber den Entwurf 
uber die Evolution des Produkts gestatten und dabei die 
funktionalen entwurfsbezogenen Aspekte eines Produkts 
(anstatt wie im Stand der Technik ledigiich die rcalisicrtcn 
45 Konfigurationen des endgultigen Produkts) erfassen und ein 
Verfolgen und Nachvollziehen deren Entwicklung gestatten. 
[0006] Demgegenuber wird erfindungsgemaB ein Objekl- 
modell zum Erfassen von Informationen mit den Merkma- 
len des Anspruchs 1, ein Verfahren zum Erfassen von Infor- 
50 mationen mit den Merkmalen des Anspmchs 10 sowie ein 
Computerprogramm mil den Merkmalen des Anspruchs 18 
vorgeschlagen. 

[0007] Die vorliegende Erfindung besteht demnach aus ei- 
nem System und einem Verfahren zum Erfassen und Spei- 
55 chem von und Zugreifen auf Innovationsinformationsdaten 
in einer bestandigen und werkzeugneutralen Form, die einen 
Datenzugnff durch jedes Werkzeug uber eine ofTentlich de- 
fimerte Schnittstelle gestattet Die Erfindung erfaBt den kla- 
ren inkrementalen Aufbau von Innovationsinformationen 
60 einschheBhch Produktideen, Gestaltungs- bzw. Entwurfsal- 
temativen, Fragen und Antworten, die wahrend des Innova- 
tionsprozesses untersucht wurden, Entwurfsentscheidungen 
usw. Die Innovationsinformationen sind in einer Form dar- 
gestellt, die unter Verwendung unterschiedlicher computer- 
65 basierter Anwendungen abgefragt und auf verschiedene 
Weisen wiedergegeben werden kann. 
[0008] Die Erfindung erfaBt den evolutionaren Aufbau 
von Informationen, die die Ausgangsidee und die Untersu- 
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chung eines Produkts uber die Zeit betreffen. Wahrend der 
Untersuchung eines Produkts werden viele Altemativen 
vorgeschlagen und erforscht. Es werden Entscheidungen ge- 
fallt, die Moglichkeiten ausschlieBen. Mit Fortschreiten der 
Gestaltung und der Ehtwicklung andern sich die gestellten 5 
Fragen und zugehorigen Antworten unter dem EinfluB von 
umfassenden Entscheidungen und dem Aufkommen von 
mehr ins Detail gehenden Fragestellungen. Teile der Pro- 
duktdefinition bewegen sich mit unterschiedlicher Ge- 
schwindigkeit von der Idee zur vollstandigen Definition. 10 
Das Innovationsinformationen-Objektmodell der Erfindung 
unterstiitzt das Verfolgen bzw. Nachvollziehen der funktio- 
nalen gestaltungsorientierten Aspekte des Produkts. Das ge- 
staltungsorientierte Verfolgen stellt somit ein Zeitspektrum 
vom Untersuchen von Produktideen bis zur vollstandigen 15 
und fur die Produktion freigegebenen Produktdefinition be- 
reit. Die Informationen entwickeln und gestalten sich gradu- 
ell und werden mit fortschreitendem GestaltungsprozeB im- 
mer detaillierter. Die Moglichkeit fur Innovation ist gege- 
ben, solange Fragen offen sind, die kreative Antworten er- 20 
fordern. Die Auswirkung von Innovation bewegt sich von 
global zu lokal, wenn Entscheidungen gefallt und Detailfra- 
gen angegangen werden. 

[0009] Die vorliegende Erfindung umfaBt vorzugsweise 
ein Objektmodell zur Verwaltung von Innovationsinforma- 25 
tionen (nachfolgend kurz als IIM-Objektmodell hezeichnet), 
das unterschiedliche Objektmodelle erfafit und speichert, 
die Informauonsartikel und deren zugehorige Beziehungen 
in einer Objektmodelldatenbank umfassen. Jedes Objektmo- 
dell beinhaltet Informationen und Beziehungen, die uber 30 
eine offentlich definierte Schnittstelle zuganglich sind. In ei- 
ner Ausfuhrungsform werden beim Speichern eines Objekt- 
modells in die Objektmodelldatenbank unterschiedliche Ty- 
pen von Informationsartikeln bzw. Einzelinformationen, die 
in dem Objektmodell zusammen mit ihren Beziehungen zu 35 
anderen Informationsartikeln bzw. Einzelinformationen ent- 
halten sind, in unterschiedlichen relationalen Datenbankda- 
teien, die mit den Informationsartikeln verknupft sind, ge- 
speichert. Anwendungen, die auf die Objektmodelldaten- 
bank zugrcifcn, vcrwcndcn lcdiglich die definierte Objckt- 40 
modellschnittstelle, was zu einer automatischen Trennung 
und Speicherung von Datentypobjekten in einer bestandigen 
werkzeugneutralen Form fiihrt 

[0010] Die Erfindung crlcichtcrt den Zugriff auf Informa- 
tionen mittels jeglicher Anwendung iiber die definierten Ob- 45 
jektmodelischnittstellen, unabhangig davon, durch welche 
Anwendung die Objekte erzeugt wurden. Dadurch entsteht 
kein "Besitz" an den Daten durch eine Anwendung oder 
durch das Werkzeug, das die Daten erzeugt hat. 
[0011] Die Erfindung erleichtert auch anspruchsvolle Su- 50 
chen in den Objekunodellen, um interessierende Informatio- 
nen aus der Gesamtheit der gespeicherten Informationen 
herauszuziehen. Die Erfindung ist in vielerlei Hinsicht vor- 
teilhaft, einschlieBlich der Moglichkeit fur eine Mehrzahl 
von Menschen mit unterschiedlichen Aufgaben und Posten, 55 
auf die Informationen zuzugreifen und diejenigen Informa- 
tionen herauszuziehen, die ihrer Aufgabe bzw. ihrer Position 
entsprechen. 

[0012] Weitere Vorteile und Ausgestaltungen der Erfin- 
dung ergeben sich aus der Beschreibung und der beiliegen- 60 
den Zeichnung. 

[0013] Es versteht sich, daB die vorstehend genannten und 
die nachstehend noch zu erlauternden Merkmale nicht nur in 
der jeweils angegebenen Kombination, sondern auch in an- 
deren Kombinationen oder in Alleinstellung verwendbar 65 
sind, ohne den Rahmen der vorliegenden Erfindung zu ver- 
lassen. 

[0014] Die Erfindung ist anhand von Ausfuhrungsbeispie- 
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len in der Zeichnung schematisch dargestellt und wird im 
folgenden unter Bezugnahme auf die Zeichnung ausfuhrlich 
beschrieben. 

[0015] Fig. 1 zeigt ein konzeptionelles Objektmodelldia- 
gramm, das die Trennung von Informationsartikeln und ih- 
rer zugeordneten Beziehungen zu anderen Informationsarti- 
keln darstellt. 

[0016] Fig. 2 zeigt ein Blockdiagramm eines erfindungs- 
gemaBen Objektmodeils zur Verwaltung von Innovationsin- 
formationen. 

[0017] Fig. 3 zeigt ein UML-Schnittstellendiagramm 
(UML: Unified Modelling Language), das eine bevorzugte 
Ausfuhrungsform der Schnittstelle fur das Objektmodell zur 
Verwaltung von Innovationsinformationen (nM-Objektmo- 
dell) fur das in Fig. 2 gezeigte IIM-Objektmodell darstellt. 
[0018] Fig. 4 zeigt ein Blockdiagramm der von dem IIM- 
Objektmodell der Fig. 2 unter Verwendung der in Fig. 3 de- 
finierten Schnittstellen erzeugten und unterhaltenen bestan- 
digen Speichereinheiten bzw: -entitaten. 
[0019] Fig. 5 zeigt ein Anschauungsbeispiel einer relatio- 
nalen Datenbankdatei, mit der eine erfindungsgemaBe Pro- 
duktidee-Tabelle umgesetzt wird. 

[0020] Fig. 6 zeigt ein Anschauungsbeispiel einer relatio- 
nalen Datenbankdatei, mit der eine erfindungsgemaBe Pro- 
duktanforderungen-Tabelle umgesetzt wird. 
[0021] Fig. 7 zeigt ein Anschauungsbeispiel einer relatio- 
nalen Datenbankdatei, mit der eine erfindungsgemaBe Ge- 
staltungsalternativen-Tabelle umgesetzt wird. 
[0022] Fig. 8 zeigt ein Anschauungsbeispiel einer relatio- 
nalen Datenbankdatei, mit der eine erfindungsgemaBe Pro- 
duktfunktion-Tabelle umgesetzt wird. 
[0023] Fig. 9 zeigt ein Anschauungsbeispiel einer relatio- 
nalen Datenbankdatei, mit der eine erfindungsgemaBe An- 
forderungserfullung-Tabelle umgesetzt wird. 
[0024] Fig. 10 zeigt einen Produktidee-Dialog fiir eine er- 
findungsgemaB umgesetzte grafische Benutzerschnittstelle. 
[0025] Fig. 11 zeigt einen Produktanforderung-Dialog fiir 
eine erfindungsgemaB umgesetzte grafische Benutzer- 
schnittstelle. 

[0026] Fig. 12 zeigt einen Produktfunktion-Dialog fiir 
eine erfindungsgemaB umgesetzte grafische Benutzer- 
schnittstelle. 

[0027] Fig. 13 zeigt einen Gestaltungsalternativen-Dialog 
fur cine erfindungsgemaB umgesetzte grafische Benutzer- 
schnittstelle. 

[0028] Fig. 1 zeigt ein konzeptionelles Blockdiagramm, 
das die Trennung von Informationsartikeln bzw. Informali- 
onsgegenstanden bzw. Einzelinformationen und deren zuge- 
horigen Beziehungen zu anderen Informationsartikeln so- 
wie die Zugreifbarkeit auf die Informationen mittels unter- 
schiedlicher Werkzeuge darstellt. Insbesondere sind eine 
Ansammlung von Objektmodellen 10a, 10b, 10c, lOd, lOe 
und lOf, die Informationen und von einer Anzahl unter- 
schiedlicher Werkzeuge 20a, 20b, 20c, . . ., 20n wahrend der 
Entwicklung eines Produktes erzeugte Objektbeziehungen 
beschreiben, in werkzeugneutraler Form in einem bestandi- 
gen Speicher 30 gespeichert. Dabei ist es wichtig, daB die 
Objektmodelle 10a, 10b, 10c, lOd, lOe und lOf nicht einem 
bestimmten Werkzeug "gehoren", insbesondere nicht den 
Werkzeugen 20a, 20b, 20c, 20n, von denen sie erzeugt wur- 
den. Jedes Objektmodell 10a, 10b, 10c, lOd, lOe und lOf 
enthalt Objekte, die hochst abhangige Objektbeziehungen 
aufweisen. 

[0029] Die Objektmodelle 10a, 10b, 10c, lOd, lOe und lOf 

verfugen jeweils uber eine definierte offentliche Schnitt- 
stelle, die es einem jeden die Schnittstellendefinition verste- 
henden Werkzeug 20a, 20b, 20c, . . ., 20n gestatteL, zulassige 
Daten in den entsprechenden Satz von Objekten zu schrei- 
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ben und herauszulesen. Auch wenn die Situation eintreten 
kann, daB lediglich ein Anwendungswerkzeug ein einzelnes 
Attribut volistandig versteht (wie ein CAD-Werkzeug, das 
eine 3D-Geonietrie und -topologie versteht), gestattet es die 
offentiiche SchnittsteUendefinition im Grunde genommen 
jedem Werkzeug, auf Teile des Objekts, das es versteht, ein- 
schlieBlich dessen Beziehungen zu anderen Objekten, zuzu- 
greifen. Beispielsweise erzeugt das CAD-Werkzeug (CAD 
TOOL) 20a (bspw. SolidDesigner von CoCreate) Daten, die 
teilweise in dem ObjektmodeU "CAD-ModeU" (CAD MO- 
DEL) 10a und teilweise in dem ObjektmodeU "Produkt- 
struktur" (PRODUCT STRUCTURE) 10b gespeichert wer- 
den. Es ist wichtig festzuhalten, daB das CAD-Werkzeug 
20a seine interne Datenstruktur oder seine Benutzersehnitt- 
steUe nicht andern muB. Vielmehr muB das CAD-Werkzeug 
20a lediglich die Fahigkeit besitzen, nur diejenigen Objekte 
und Strukturen zu verstehen, die es schreibt und best, was 
durch Verwenden einer Erweiterung erreicht werden kann, 
die eine Import/Exportfahigkeit gestattet; derartige Techni- 
ken sind im Stand der Technik gut bekannt. In dem vorlie- 
genden Beispiei greift ein PDM- Werkzeug (PDM TOOL) 
20b (PDM: Product Data Management; bspw. WorkMana- 
ger von CoCreate) auf das Modeil "Produktstruktur" 10b 
und das Modell "Gestaltungsalternative" (DESIGN AL- 
TERNATIVE) 10c zu. Entsprechend muB das PDM- Werk- 
zeug 20b die Fahigkeit besitzen, an dem Modell "Produkt- 
struktur" 10b von dem CAD-Werkzeug 20a vorgenomme- 
nen Anderungen handhaben zu konnen, und entsprechend 
muB das CAD-Werkzeug 20a die Fahigkeit besitzen, von 
dem PDM-Werkzeug 20b an dem Modell "Produktstruktur" 
10b vorgenommenen Anderungen handhaben zu konnen. 
Das gemeinsame ObjektmodeU (d. h. das ModeU "Produkt- 
struktur" 10b), das beide verstehen, unterstutzt und verbes- 
sert dabei die KoUaboration zwischen dem CAD-Werkzeug 
20a und dem PDM-Werkzeug 20b. 

[0030] Es ist auch wichtig festzuhalten, daB anderen 
Werkzeuge (bspw. 20n) auch jederzeit auf die Objektmo- 
deUe 10a, 10b, 10c, 10d, lOe und lOf zugreifen konnen und 
die Anzahl von ObjektmodeUen 10a, 10b, 10c, lOd, lOe und 
lOf jcdcrzcit crwcitcrt wcrdcn kann. So crwcitcrt und cnt- 
wickelt sich die Sammlung von Informationen und Bezie- 
hungen mit anderen Objekten entsprechend wahrend des 
Fortgangs des Produktzyklus, wobei die Entwicklungs- und 
Gcstaltungsaspcktc des Produkts fcstgchaltcn wcrdcn. Zu- 
dem gestattet die werkzeugneutrale bestandige Form der 
ObjektmodeUe sowohl synchrone als auch asynchrone Kol- 
laboralion bei der Produktentwicklung, indem vielen unter- 
schiedlichen Benutzern (bspw. Ingenieure, Entscheidungs- 
ebene, Verwaltungspersonal und sogar Kunden) mit entspre- 
chender Berechtigung zum Zugriff auf die in den Objektmo- 
deUen enthaltenen Daten, die den derzeiugen Stand des Pro- 
dukts darsteUen, gestattet ist. 

[0031] Unter den ObjektmodeUen in der ObjektmodeUda- 
tenbank 30 befindet sich ein ObjektmodeU "Verwaltung von 
Innovalionsinformationen" (INNOVATION INFORMA- 
TION MANAGEMENT) lOe (kurz: EM-ObjektrnodeU), 
das aU diejenigen Innovationsinformauonen einschlieBt 
bzw. zusammenfaBt, die mit der Entwicklung und Gestal- 
tung eines Produkts, einschUeBUch Produktideen, Gestal- 
tungsalternativen, Fragen und Antworten, die wahrend des 
Innovationsprozesses untersucht wurden, Gestaltungsent- 
scheidungen usw., verbunden sind sowie ihre Beziehungen 
zu anderen Objekten in dem HM-Objektmodell lOe und zu 
Objekten in anderen ObjektmodeUen 10a, 10b 10c 10c 
lOdundlOf. 

[0032] Objekte in dem HM-ObjektmodeU lOe konnen au- 
tomatisch von einem oder mehreren der Werkzeuge 20a, 
20b, 20c, 20n erzeugt werden, oder sie konnen konkret 



von Nutzern uber spezifische IIM-Dialoge (HM: Innovati- 
onsinformationen-Management/Innovation Information 
Management) erzeugt werden, auf den uber die Benutzer- 
schnittsteUe der Werkzeuge zugegrififen wird. ZusatzUch 
5 kann ein HM-Werkzeug (TOOL) 20c zur konkreten Eingabe 
yon Innovationsinformationsdaten entwickelt werden. Wie 
jedoch schon vorstehend angemerkt wurde, "gehoren" kei- 
nem Werkzeug die Daten in dem HM-ObjektmodeU lOe und 
jedes Werkzeug kann auf die Daten in dem HM-Objektmo- 
10 deU lOe uber offendich definierte SchnittsteUen, die mit 
dem HM-ObjektmodeU lOe in Verbindung stehen, zugrei- 
fen. Diese offendich definierten SchnittsteUen werden nach- 
folgend noch ausfuhriich erlautert. 

[0033] Fig. 2 zeigt ein Blockdiagramm, das eine bevor- 
15 zugte Ausfuhrungsform 100 des HM-Objektmodells der 
fig. 1 darsteUt, durch das ein ObjektmodeU zum Erfassen 
und Speichern der einzelnen Informationen und deren 
Struktur, wie sie wahrend der Untersuchungsphase der Ent- 
wicklung und Gestaltung eines Produkts in einer werkzeug- 
20 neutralen bestandigen Form entwickelt wurden, bereitsteUt. 
[0034] Wie in Fig. 2 dargesteUt umfassen die hauptsacMi- 
chen Informationsgegenstande in dem HM-ObjektmodeU 
100 die folgenden Objekte: Produktidee (PRODUCT IDEA) 
110, Produktanforderung (PRODUCT REQUIREMENT) 
25 120, Gestaltungsalternative (DESIGN ALTERNATIVE) 
130, Gestaltungsdarstellung (DHSrGN REPRESENTA- 
TION) 140, Produktfunktion (PRODUCT FUNCTION) 
150, Durchfuhrungsbeschrankung (REGULATORY CON- 
STRAINT) 160, Gestaitungsabsicht (DESIGN INTENT) 
30 170, GestaJtungsmerkmai bzw. Gestaltungsbedeutung bzw 
Gestaltungsanmerkung (DESIGN NOTE) 180, Gestaltungs- 
problem (DESIGN ISSUE) 190 und Gestaltungsbeschran- 
kung (DESIGN CONSTRAINT) 195. 
[0035] Ein Informationsgegenstand (oder Inforrnations- 
35 objekt) "Produktidee" 110 scMieBt eine Idee betreffend ein 
Produkt ein. Eine Produktidee kann eine Idee fur ein neues 
Produkt, eine Steigerung oder Verbesserung eines bestehen- 
den Produkts oder die Losung eines bekannten Problems 
(wie eine technische Anderung) fiir ein bestehendes Produkt 
40 scin. 

[0036] Ein Objekt "Produktanforderung" 120 beinhaltet 
eine Anforderung, die das Produkt erfUUen muB, soU oder 
kann. Fur ein gegebenes Produkt gibt es UbUcherweise viele 
Anfordcrungcn von viclcn vcrschicdcncn QucUcn (bspw. 
45 Marketing, Kunden, Entwicklung, HersteUung). 

[0037] Ein Objekt "Gestaltungsalternative" 130 fa8t In- 
fonnalionen zusammen, die eine mogiiche Losung Oder Ge- 
staltung fur eine Idee darsteUen, die in einem Objekt "Pro- 
duktidee" 110 zusanimengefaBt isL Ein Objekt "Gestal- 
50 tungsdarsteUung" 140 beinhaltet eine MogUchkeit, die in ei- 
nem Objekt "Geslaltungsalternative ,, 130 dargesteUte vorge- 
schlagene Losung oder Gestaltung umsetzen bzw. herstel- 
len. 

[0038] Ein Objekt "Produktfunktion" 150 beinhaltet eine 
55 Funktion zum Losen einer Produktanforderung. 

[0039] Ein Objekt "Durchfuhrungsbeschrankung" 160 be- 
inhaltet eine Beschrankung, die dem Produkt auferlegt ist 
und sich auBerhalb der Kontrolle der Entwickler/Gestalter 
befindet. Als Beispiei seien hier gesetzlich festgelegte Kom- 
60 munikationsfrequenzen im Funkbereich genannt 

[0040] Ein Objekt "Gestaitungsabsicht" 170 beinhaltet 
eine konkrete Absicht oder Zielsetzung der Gestaltung. 
[0041] Ein Objekt "Gestaltungsmerkmal" 180 beinhaltet 
ein die Gestaltung betrefTendes Merkmal. 
65 [0042] Ein Objekt "Gestaltungsproblem" 190 ist mit einer 
GestaltungsdarsteUung verbunden. Das in einem Gestal- 
tungsproblem-Objekt enthaltene bzw. zusammengefafite 
Problem betriftt Bedenken oder eine offene Frage, die nach 
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Betrachten der Darstellung der Gestaltungsaltemative auf- 
gekommen sind.- 

[0043] Ein Objekt "GestaUungsbeschrankung" 195 fafit 
eine Beschrankung zusaimnen, die der Gestaltungsalterna- 
tive auferlegt ist und iiber die Kontrolle besteht. 
[0044] Innerhalb des IIM-Objektmodells 100 existieren 
Beziehungen zwischen den Datenobjekten, wie dies durch 
die Verbindungslinien zwischen den Objekten dargestellt 
ist. Z. B. kann jede Produktidee 110 mil verschiedene Pro- 
duktanforderungen 120 (wie sie von den Entwicklem und 
anderen die Gestaltung beeinflussenden Personen definierl 
werden) verbunden sein, die wiederum keine oder mehrere 
zugeordnete Produktfunklionsobjekte 150 aufweisen kon- 
nen, die vollstandig oder teilweise die in ihrem zugeordne- 
ten Produktanforderungsobjekt 120 niedergelegten bzw. zu- 
sammengefaBten Anforderungen erfiillen. Jede Produktidee 
110 kann auch mit einigen Durchfuhrungsbeschrankungen 
160 (wie sie bspw. durch die Industrie oder den Gesetzgeber 
definiert sein konnen) verbunden sein, die wiederum durch 
eine Produktanforderung 120 wie vorstehend beschrieben 
dargestellt sein konnen. Jede Produktidee 110 kann auch mit 
mehreren Gestaltungsalternativobjekten 130 verbunden 
sein, die wiederum mil Gestaltungsabsichtsobjekten 170 
und zugeordneten Produktfunktionsobjekten 150 verbunden 
sein konnen. AuBerdem kann jede Gestaltungsaltemative 
zugeordnete Gestakungsbeschrankungen 195 und/oder zu- 
geordnete Gestaltungsdarstellungen 140 aufweisen. Jede 
Gestaltungsdarstellung 140 kann zugeordnete Gestaltungs- 
bemerkungen 180 und/oder Gestaltungsprobleme 190 auf- 
weisen. 

[0045] Fig. 3 zeigt ein UML-Schnittstellenddagrarnm, das 
eine bevorzugte Ausfuhrungsform der IIM-Objektmodell- 
schnittstelle fur das IIM-Objektmodell 100 der Fig* 2 dar- 
stellt. Wie in Fig. 3 dargestellt umfassen die fur das DM-Ob- 
jektmodell 200 der Fig. 2 definierten offentlichen Schnitt- 
stellen folgendes: Produktidee (Productldea) 210, Produk- 
tanforderung (ProductRequirement) 220, Gestaltungsalter- 
native (DesignAltemative) 230, Gestaltungsdarstellung 
(DesignRepresentation) 240, Produktfunktion (Product- 
Function) 250, Durch fuhrungsbcschrankung (Regulatory- 
constraint) 260, Gestaltungsabsicht (Designlntent) 270, Ge- 
staltungsbemerkung (DesignNote) 280, Gestaltungsproblem 
(Designlssue) 290, GestaUungsbeschrankung (DesignCon- 
straint) 295 und Produktspczifikation (Products prcification) 
225. Die Attribute fur jede Schnittstelle sind wie in Fig. 3 
dargestellt. In der HM-Schnittstellendefinition werden In- 
fonnaUonen uber jede Produktidee in einem Objekt "Pro- 
duktidee" 110 (Fig. 2) zusammengefaBt, auf das von der 
Schnittstelle Productldea 210 zugegriffen wird. In dieser 
Ausgestaltung hat die Schnittstelle Productldea 210 keine 
oder mehrere Schnitlstellen RegulatoryConslraint 260, von 
denen jede mit keiner oder mehreren Schnittstellen Produc- 
tRequirement 220 verbunden sein kann. Die Schnittstelle 
Productldea 210 kann auch eine Zuordnung zu keiner oder 
mehreren Schnittstellen ProductRequirement 220 aufwei- 
sen, die aus verschiedenen Quellen stammen konnen und 
eine angehangte Beziehiing, die uber die Schnittstelle Re- 
quirementRelationship 222 definiert ist, aufweisen konnen. 
Eine Schnittstelle ProductSpecificauon 225 ist eine Erweite- 
rung der Schnittstelle ProductRequirement 220 und wird 
dazu verwendet, Spezifikationen fiir die Anforderungen ge- 
nauer zu definieren. Jede Schnittstelle ProductRequirement 
220 kann auch keiner oder mehreren Schnittstellen Product- 
Function 250 zugeordnet sein, die eine Losung zum teilwei- 
sen oder vollstandigen Erfiillen einer Produktanforderung 
bereitstellen. Die Schnittstelle ProductFunction 250 ist in 
der standardisierten Schnittstelle PDMConfigurationMana- 
gement der "Object Management Group (OMG) PDM En- 



ablers" definiert, die aus dem Stand der Technik bekannt und 
in "PDM Enablers: Joint Proposal to the OMG in Response 
to OMG Manufacturing Domain Task Force RFP 1", Paper 
mfg/98-02-02 of der Object Management Group (OMG), 

5 ausfuhrlich beschrieben ist. Die Schnittstelle PDMConfigu- 
rationManagement erweitert den Produktstruktur-Enabler 
zur Unterstutzung von Unternehmen, in denen ein Produkt 
zum Verkauf in vielen unterschiedlichen Komponentenkon- 
figurationen angeboten werden kann. Das Konfigurationen- 

10 verwaltungsmodul erlaubt eine Spezifikation von Produkt- 
klassen und unterscheidenden Produktkonfigurationen. Ent- 
sprechend ist das IIM-Objektmodell der Erfindung kompati- 
bel mit den standardisierten PDM-Enabler-Schnittstellen. 
[0046] Wie ebenfalls dargestellt kann die Schnittstelle 

15 Productldea 210 keiner oder mehreren Schnittstellen Desi- 
gnAltemative 230 zugeordnet sein^ die einen Zugriff auf 
keine oder mehrere Objekte "Gestaltungsaltemative" 130, 
die einem bestimmten Objekt "Produktidee" 110 zugeordnet 
sind, gestatten. Jede Schnittstelle DesignAltemative 230 hat 

20 keine oder mehrere Schnittstellen DesignConstraint 295 und 
keine oder mehrere Schnittstellen DesignRepresentation 
240, die jeweils Zugriff auf ein verbundenes Objekt "Gestal- 
tungseinschrankung" 195 und/oder ein zugehoriges Objekt 
"Gestaltungsdarstellung" 140 gestatten. Jede Schnittstelle 

25 DesignRepresentation 240 ist keiner oder mehreren Schnitt- 
stellen DesignNote 280 zugeordnet, die Zugriff auf ein Ob- 
jekt "Gestaltungsbemerkung" 180 gestatten, und mit keiner 
oder mehreren Schnittstellen Designlssue 290, die Zugriff 
auf ein Objekt "Gestaltungsproblem" 190 gestatten. . 

30 [0047] Eine Schnittstelle RequirementFulfillment. 255 ge- 
stattet, auf den Grad der Erfullung der Produktanforderun- 
gen, die die Produktfunktion erfullt, zuzugreifen. Dies ge- 
stattet einem Benutzer, das IIM-Objektmodell spater im 
Hinblick auf diejenigen CJestaltungsalternativen, die be- 

35 stimmte ggf. prioritatsgewichtete Anforderungen erfiillen, 
zu untersuchen, um zu ermitteln, welche Gestaltungsaltema- 
tive einer Erfullung der Anforderungen mit den hochsten 
Prioritaten am nachsten kommt. 

[0048] Diese Fahigkeit, das System abzufragen, inderri 
40 wichtigc Fragcn gcstcllt werden, und cine automatischc 
Antwort von dem HM-Objektmodell zu erhalten, ist ein au- 
Berst wichtiger Aspekt, der durch die Erfindung bereitge- 
stellt wird. 

[0049] Ein Satz von Entschcidungsschnittstcllcn gestatten 

45 einem Benutzer, unterschiedliche Entscheidungen, die wah- 
rend der Untersuchungsphase des Produkts getroffen wur- 
den, zu erfassen und aufzufinden. Bspw. gestatlet eine 
Schnittstelle ProductRequirementDecision 215 das Auffin- 
den von Fragen, Antworten und daraus resultierenden Ent- 

50 scheidungen, die mit Produktanforderungen verbunden 
sind. Eine Schnittstelle ProductFunctionDecision 235 ge- 
stattet das Auffinden von Fragen, Antworten und daraus re- 
sultierenden Entscheidungen, die mit der Verwendung von 
vorgeschlagenen Produktfunktionslosungen in einer be- 

55 stimmten Gestaltungsaltemative verbunden sind. Eine 
Schnittstelle DesignAlternativeDecision 275 gestattet das 
Auffinden von Fragen, Antworten und daraus resultierenden 
Entscheidungen, die mit der Auswahl von Gestaltungsalter- 
nativen verbunden sind. Eine Schnittstelle DesignRepresen- 

60 tationDecision 245 gestattet das Auffinden von Fragen, Ant- 
worten und daraus resultierenden Entscheidungen, die mit 
der Auswahl in der Implementierung einer bestimmten Ge- 
staltungsaltemative verbunden sind. 

[0050] Die in dem UML-Diagramm der Fig. 3 definierten 
65 Schnittstellen sind vorzugsweise in einer objektorientierten 
Sprache wie C++ oder Java2 implementiert. Die tatsachli- 
che Klassenimplementierung kann von System zu System 
variieren, da es haufig sinnvoll sein wird, einige der Schnitt- 
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stellen aus Griinden einer effizienten Implementierung und/ 
Oder Leistung (Performance) in einer einzelnen Klasse zu- 
sammenzuf assen . 

[0051] Fig. 4 zeigt ein Blockdiagramm, das eine Ausfuh- 
rungsform der bestandigen Speicherentitaten darsteUt, die 
von dem HM-ObjektmodeU 100 der Fig. 2 unter Verwen- 
dung der in Fig. 3 definierten Schnittstellen erzeugt und un- 
terhalten werden. In dieser Ausfuhrungsform ist mit jeder 
SchnittsteUe eine bestandige Speicherdatei, vorzugsweise in 
Form einer reiationalen Datenbank, verbunden. Die von der 
jeweiligen SchnittsteUe eingeschlossenen Daten sind in der 
jeweiligen zugehorigen reiationalen Datenbankdatei gespei- 
chert. Entsprechend gibt es eine separate relationale Daten- 
bankdatei fiir jede definierte Schnittstelle. In dem dargesteU- 
ten Ausfuhrungsbeispiel speichert eine Tabelle "Produkti- 
dee" (PRODUCT IDEA TABLE) 310 alle verrugbaien Da- 
ten, die die Schnittstelle Productidea 210 verwenden, eine 
Tabelle "Produktanforderung" (PRODUCT REQUIRE- 
MENT TABLE) 320 speichert alle zugegriffenen Daten, die 
die Schnittstelle ProductRequirement 220 verwenden, eine 
TabeUe "Gestaltungsalternativen" (DESIGN ALTERNA- 
TIVE TABLE) 330 speichert alle zugegriffenen Daten, die 
die Schnittstelle DesignAltemative 230 verwenden, eine Ta- 
beUe "GestaltungsdarsteUung" (DESIGN REPRESENTA- 
TION TABLE) 340 speichert alle zugegriffenen Daten, die 
die Schnittstelle DesignRepresentation 240 verwenden, eine 
Tabelle "Produktfunktion" (PRODUCT FUNCTION TA- 
BLE) 350 speichert alle zugegriffenen Daten, die die 
Schnittstelle ProductFunction 250 benutzen, eine TabeUe 
"Durchfuhrungsbeschrankung" (REGULATORY CON- 
STRAINT TABLE) 360 speichert aUe zugegriffenen Daten, 
die die SchnittsteUe RegulatoryConstraint 260 verwenden' 
eine TabeUe "Gestaltungsabsicht" (DESIGN INTENT TA- 
BLE) 370 speichert aUe zugegriffenen Daten, die die 
SchnittsteUe Designlntent 270 benutzen, eine TabeUe "Ge- 
staltungsbemerkung" (DESING NOTE TABLE) 380 spei- 
chert aUe zugegriffenen Daten, die die SchnittsteUe De- 
signNote 280 benutzen, eine TabeUe "Gestaltungsproblem" 
(DESIGN ISSUE TABLE) 390 speichert alle zugegriffenen 
Daten, die die Schnittstelle Dcsignlssuc 290 verwenden. Zu- 
satzlich speichern die EntscheidungstabeUen "Produktan- 
forderungsentscheidung" (PRODUCT REQUIREMENT 
DECISION TABLE) 315, "Produktrunkuonsentscheidune" 
(PRODUCT FUNCTION DECISION TABLE) 335, "Gc- 
staltungsdarsteUungsentscheidung" (DESIGN REPRESEN- 
TATION DECISION TABLE) 345, "Gestaltungsalternati- 
venenlscheidung" (DESIGN ALTERNATIVE DECISION 
TABLE) 375 jeweils die zugegriffenen Daten, die die 
SchnittsteUen ProductRequirementDecision 215, Product- 
FunctionDecision 235, DesignRepresentationDecision 245 
und DesignAUernauveDecision 275 benutzen. Eine TabeUe 
"AnforderungserfuUung" (REQUIREMENT FULFILL- 
MENT TABLE) 355 speichert die zugegriffenen Daten, die 
die SchnittsteUe RequirementFulfiUment 255 benutzen. Die 
gestrichelten Linien, die die unterschiedlichen TabeUen mit- 
einander verbinden, steUen einen fremden Schlussel (fo- 
reign key) dar (d. h. eine gemeinsame Spalte in jeder ver- 
bundenen reiationalen Datenbank), der zur DarsteUung der 
Beziehungen in den TabeUen gespeicherten Daten verwen- 
det wird. 

[0052] Fig. 5 ist ein Anschauungsbeispiel einer reiationa- 
len Datenbankdatei 410, die eine TabeUe "Produktidee" 310 
darsteUt. Wie dargesteUt, biidet jede Spalte "Beschreibung" 
(Description) 501 und "Name" 502 auf ein in der Schnitt- 
steUe Productldea 210 eingeschlossenes bzw. enthaltenes 
Attribut ab bzw. verweist auf dieses, und jede Reihe biidet 
auf ein unterschiedhches Objekt "Produktidee" 110 ab. 
[0053] Fig. 6 zeigt ein Anschauungsbeispiel einer relatio- 
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nalen Datenbankdatei 420, die eine TabeUe "Produktanfor- 
derung" 320 umsetzt. Wiederum biidet jede Spalte "Pro- 
duktideenname" (Product Idea Name) 601, "Beschreibung" 
(Description) 602, "Name" 603, "Kennung" (ID) 604, "Prio- 
5 ritat" (Priority) 605 und "Gewichtung" (Weight) 606 jeweils 
auf ein in der SchnittsteUe ProductRequirement 220 einge- 
schlossenes bzw. enthaltenes Attribut ab bzw. verweist auf 
dieses, und jede Reihe biidet ein unterschiedhches Objekt 
"Produktanforderung" 120 ab. In diesem Beispiel ist der Pri- 
10 marschlussel (d. h. ein einziges Schiusselfeld (Identifier) fur 
die gesamte Datei) fur jedes Objekt "Produktanforderung" 
320 dessen Produktanforderungserkennung (in dieser Aus- 
fuhrungsform in Spalte 603 gespeichert). Das Attribut "Pro- 
duktideename" des Objekts "Produktidee", mit dem das Ob- 
is jekt "Produktanforderung" 120 verbunden ist, wird als frem- 
der Schlussel bzw. Kennbegriff verwendet Entsprechend 
wird eine Spalte "Fremder Schliissel" 601 bereitgestellt, urn 
jeweUige Objekte "Produktanforderung" auf die zugeordne- 
ten Objekte "Produktidee" abzubilden. 
20 [0054] Fig. 7 zeigt ein Anschauungsbeispiel einer reiatio- 
nalen Datenbankdatei 430, die eine Tabelle "Gestaitungsal- 
ternative" 330 umsetzt Die TabeUe umfaBt die Spalten 
("Produktideenname" (Product Idea Name) 701, "Beschrei- 
bung" (Description) 702, "Name" 703, "Status" 704 "Sta- 
25 tusgrund" (Status Reason) 705 und "Geschichte" (History) 
706. Tn diesem Beispiel wird das Attribut "Produktideen- 
name" des Objekts "Produktidee", dem das Objekt "Gestal- 
tungsalternative" 130 zugeordnet ist, als fremder Schlussel 
verwendet. Entsprechend wird eine Spalte "Fremder Schlus- 
30 sel" 701 bereitgestellt, urn jeweilige Objekte "Gestaltungs- 
alternative" auf die zugeordneten Objekte "Produktidee" ab- 
zubilden. 

[0055] Fig. 8 ist ein Anschauungsbeispiel einer reiationa- 
len Datenbankdatei 450, die eine TabeUe "Produktfunkuon" 
35 350 umsetzt. Die TabeUe umfaBt die Spalten "Produktanfor- 
derungskennung" (Product Requirement ID) 801, "Gestal- 
tungsalternativenname" (Design Alternative Name) 802 
"Beschreibung" (Description) 803, "Name" 804, "Relevanz" 
(is_relevant_for) 805. In diesem Beispiel wird das Attribut 
40 "Produktanfordcrungskcnnung" des Objekts "Produktanfor- 
derung", dem das Objekt "Produktfunktion" 150 zugeordnet 
ist, als ein fremder Schlussel und das Attribut "Gestaltungs- 
altemativenname" des Objekts "Gestaltungsalternative", 
dem das Objekt "Produktfunktion" 150 zugeordnet ist, als' 
45 anderer fremder Schlussel verwendet. Entsprechend werden 
jeweiUge Spalten "Fremder Schlussel" 801 und 802 bereit- 
gesteUu urn Objekte "ProdukuAinklion" 150 auf ihre jeweih- 
gen zugeordneten Objekte "Produktanforderung" 120 und 
"Gestaltungsalternative" 130 abzubilden. 
50 [0056] Fig. 9 ist ein Anschauungsbeispiel einer reiationa- 
len Datenbankdatei 455, die eine TabeUe "Anforderungser- 
fuUung" 355 umsetzt. Die Tabelle umfaBt die Spalten "Pro- 
duktfunktionsname" (Product Function Name) 901 und 
"Prozent" (Percent) 902. Wie dargesteUt, bUdet die Spalte 
55 902 auf das Attribut "Prozent" ab, das uber die SchnittsteUe 
RequirementFulfiUment" 255 eingeschlossen ist, und jede 
Reihe biidet auf ein anderes Objekt "Produktfunktion" ab. In 
diesem Beispiel wird das Attribut "Produktfunktionsname" 
des Objekts "Produktfunktion" 150 als fremder Schlussel 
60 verwendet, entsprechend wird eine Spalte "Fremder Schlus- 
sel" 901 bereitgesteUt, urn ein Objekt "Anforderungserful- 
lung" auf sein zugeordnetes Objekt "Produktfunktion" 150 
abzubilden. 

[0057] Die anderen in Fig. 4 dargesteUten TabeUen sind in 
65 reiationalen Datenbankdateien umgesetzt, die den in den 
Fig. 5 bis 9 dargesteUten ahnlich sind. 
[0058] Die Ablaufe, durch die bestimmte HM-Daten er- 
faBt werden, unterscheiden sich und sind abhangig davon, 
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welcher Typ von Daten erfaBt wird. Daten konnen erfaBt 
werden, wenn ein Benutzer Daten iiber eine Dialogschnitt- 
stelle manuell eingibt (bspw. wenn ein Benutzer eine Pro- 
duktidee und zugeordnete vorgeschlagene Gestaltungsalter- 
nativen, Produktanforderungen und/oder Produktfunktionen 5 
unter Verwendung eines Produktideedialogs in der Benut- 
zerschnittstelle der Anwendung eingibt), oder konnen von 
einer Anwendung automatisch erzeugt werden (bspw. kon- 
nen Attribute wie Objektkennzeichner (Identifiers), Erzeu- 
gungszeit oder Datum der letzen Anderung von der Anwen- 10 
dung zu dem Zeitpunkt; an dem eine Information erfaBt oder 
geandert wird, automatisch erzeugt oder erfaBt werden). 
Fig. 10 zeigt beispielhaft einen Produktideedialog "Product 
Idea" 1000 einer grafischen Benutzerschnittstelle fur eine 
allgemeine Anwendung, die die Fahigkeit hat, auf ein erfin- .15 
dungsgemaBes IIM-Objektmodell lOe zuzugreifen und ein 
solches zu erzeugen. Wie dargestellt umfaBt der Produkt- 
ideedialog 1000 Benutzermoglichkeiten zum Eingeben ei- 
ner Beschreibung "Description" 1002 einer Produktidee und 
eines Namens "Name" 1004 fur die Produktidee. Der Pro- 20 
duktideedialog 1000 umfaBt auch Benutzermoglichkeiten 
(bspw. Knopfe 1006 und 1008) zum Eingeben vorgeschla- 
gener Produktanforderungen ("Requirement" 1006) undGe- 
staltungsalternativen ("Design Alternative" 1008) fur die 
Produktidee. Insbesondere wird ein in Fig. 11 dargestellter 25 
Produktanfbrderung-Dialog 1010 geoffnet bzw. eingeblen- 
det, wenn der Benutzer auf den Knopf "Requirement" 1006 
klickt. Wie in Fig. 1 1 dargestellt gestattet der Produktanfor- 
derungdialog "ProductRequirement" 1010 dem Benutzer, 
eine Beschreibung ("Description") 1012 der Produktanfor- 30 
derung, einen Namen 1014 fur die Produktanforderung und 
eine der Produktanforderung zugewiesene Prioritat ("Prio- 
rity Level") 1016 einzugeben. 

[0059] Auf die Benutzermoglichkeit zum Eingeben einer 
oder mehrerer vorgeschlagener Produktfunktionen zum teil- 35 
weisen oder voilstandigen Erfullen der Produktanforderung 
kann durch KUcken eines Knopfes "Function" 1018 zuge- 
griffen werden, wodurch ein in Fig. 12 dargestellter Dialog 
"Product Function" 1020 geoffnet bzw. eingeblendet wird. 
Wic in Fig. 12 dargestellt, kann der Benutzer die Fcldcr 40 
"Description" 1022 und "Name" 1024 der Funktion ausful- 
len und wahlweise an das Funktionsobjekt einen definierten 
Abschnitt (der dem System bekannt ist) anhangen, der der 
Anwendung gestattet, automatisch ein Objckt "Anfordc- 
rungserfiillung" 255 zu erzeugen, das angibt, wie gut die 45 
Produktfunktion die Produktanforderung erftillt. Unter 
"Function Definition" 1026 kann eine Funktionsdefinition 
eingegeben werden. 

[0060] Fig, 13 zeigt beispielhaft einen Gestaltungsalterna- 
tive-Dialog "Design Alternative" 1030, der von dem Dialog 50 
"Productldea" 1000 durch Klicken auf den Knopf "Geslal- 
tungsalternative" (Design Alternative) 1008 erreicht werden 
kann. -Wie dargestellt, gestattet der Dialog "Design Alterna- 
tive" 1030 einem Benutzer, eine Beschreibung ("Descrip- 
tion") 1032 einen Namen 1034, einen Status 1036 und einen 55 
Grund ("Reason") 1038 fur den Status 1036 einzugeben. 
Der Dialog "Design Alternative" 1030 kann auch einen 
Knopf "Produktfunktion" (Funktion) 1040 umfassen, der 
den Benutzer zu dem Produktfunktions-Dialog 1020 der 
Fig. 12 fuhrt, sowie einen Knopf "Produktfunktionsent- 60 
scheidung" (FunktionDecision) 1042, der einen (nicht dar- 
gestellten) Dialog offhet bzw. einblendet, der dem Benutzer 
gestattet, eine Entscheidung iiber jede den Gestaltungsent- 
wurf zugeordnete Produktfunktion einzugeben. 
[0061] Wie vorstehend ausfuhrlich beschrieben wurde, 65 
stellt die Erfindung einen neuen Weg des Erfassens und 
Speichems von sowie des Zugriffs auf Daten im Zusammen- 
hang mit der Verwaltung von Innovauonsinformationen dar, 
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einschlieBlich dem inkrementalen Aufbau von Innovations- 
informationen einschlieBlich Produktideen, Gestaltungsal- 
ternativen, Fragen und Antworten, die wahrend des Innova- 
tionsprozesses untersucht wurden, Gestaltungsentscheidun- 
gen usw. Die Innovationsinformationen werden in einer 
Form dargestellt, auf die in unterschiedlicher Weise zuge- 
griffen werden kann und die auf unterschiedliche Weise dar- 
stellbar ist, unter Verwendung von computerbasierten An- 
wendungen. 

[0062] Die Erfindung erfafit den evulotionaren Aufbau 
von Informationen, die die urspriingliche Idee (Ausgangs- 
idee) und die Untersuchung eines Produkts iiber die Zeit be- 
treffen. Wahrend der Untersuchung eines Produkts werden 
viele Alternativen vorgeschiagen und erforscht. Entschei- 
dungen werden gefallt, die Moglichkeiten ausraumen bzw. 
ausschlieBen. Mit fortschreitender Gestaltung andem sich 
die gesteliten Fragen und zugehorigen Antworten, da urn- 
fassende Entscheidungen gefallt werden und detailliertere 
Fragestellungen auftreten.Teile der Produktdefinidon bewe- 
gen sich von dem Status der Idee zu der fertigen Definition 
mit unterschiedlicher Geschwindigkeit. Das erfindungsge- 
maBe Objektmodell zur verwaltung von Innovadonsinfor- 
mationen unterstutzt dabei das Auffinden bzw. Nachvollzie- 
hen der funktionalen Wie-Ausgefuhrt-Aspekte des Pro- 
dukts. Dieses Auffinden stellt somit ein Zeitspektrum von 
der Untersuchung von Produktideen zu der voilstandigen 
und fur die Produktion freigegebenen Produktdefinidon be- 
reit. Die Informationen entwickeln sich dabei graduell und 
werden mit fortschreitendem GestaltungsprozeB detaillier- 
ter. Die Moglichkeit fur Innovation ist so lang gegeben, so 
lange Fragen offen bleiben, die kreative Antworten benoti- 
gen. Die Auswirkung von Innovation bewegt sich von der 
umfassenden Ebene auf detailliertere Ebenen, wenn Ent- 
scheidungen gefallt werden und Details berucksichtigt wer- 
den. 

[0063] Die Erfindung vereinfacht den Zugriff auf Infor- 
mationen durch jede Anwendung iiber die definierten Ob- 
jektmodellschnittstellen, unabhangig davon, welche An- 
wendung die Objekte erzeugt hat Somit "gehoren" die Da- 
ten kcincr Anwendung und auch kcincm Wcrkzcug,.das die 
Daten erzeugt hat. 

[0064] Die Erfindung vereinfacht auch anspruchsvolle Su- 
chen in den Objektmodellen, um interessierende Informado- 
ncn aus der Gcsamthcit der. gcspcichcrtcn Informationen 
herausfinden. Die Erfindung ist aus vielen Griinden vorteil- 
haft, einschlieBlich der Tatsache, daB viele Benutzer mit un- 
terschiedlichen Aufgaben auf eine Art und Weise, die ihrer 
jeweiligen Aufgabe bzw. Bedeutung gerecht wird, auf die 
Informationen zuzugreifen und Informationen herauszuzie- 

hen. - 

[0065] Wie nach der Leklure der vorstehenden ausfiihrli- 
che Beschreibung offensichdich wird, verfugt die Erfindung 
iiber einige Vorteile gegenuber. dem Stand der Technik. Das 
erfindungsgemafie IIM-Objektmodell erhoht die Effizienz 
beim Nachvollziehen und Verstehen, wie und warum eine 
Produktgestaltung eine derzeidge Konfiguradon aufweist. 
Das erfindungsgemaBe IIM-Objektmodell gestattet das Er- 
fasseo und Nachvollziehen von funkdonalen Wie-Gestaltet- 
Aspekten des Produkts anstelle der Wie-Ausgefuhrt-Konfi- 
guradon des endguldgen Produkts und stellt dadurch ein 
Zeitspektrum von der anfanguchen Untersuchung von Pro- 
duktideen bis zu der voilstandigen und zur Produktion frei- 
gegebenen Produktdefinidon bereit. Die InformaUonen ent- 
wickeln sich graduell und werden mit fortschreitendem Ge- 
staltungsprozeB immer detaillierter. 
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Patentanspriiche 



1. ObjektmodeU zum Erfassen von Informationen, die 
produktinnovationsbezogene Daten betreffen, mil einer 
Produktideeschnittstelle zum Erfassen einer Idee fur 
ein Produkt in einem Produktideeobjekt und einer Ge- 
staltungsalternativenschnittstelle zum Erfassen einer 
VIelzahl von Gestaltungsaiternativen ftir das Produkt in 
einer VIelzahl von jeweiligen Gestaltungsalternative- 
Objekten. 

2. Objektmodell nach Anspruch 1, mit einer Produk- 
tanforderungsschnittstelle zum Erfassen einer Anfor- 
derung fur die Produktidee in einem Produktanforde- 
rungsobjekt. 

3. Objektmodell nach Anspruch 2, mit einer Produkt- 
funktionsschnittstelle zum Erfassen einer Funktion 
zum Erfullen der Produktanforderung in einem Pro- 
duktfunktionsobjekt. 

4. Objektmodell nach Anspruch 3, mit einer Produkt- 
erfullungsschnittstelle, die erfafit, wie gut die Produkt- 
funktion die Produktanforderung erfullL 

5. Objektmodell nach Anspruch 1, mit einer Gestal- 
tungsdarstellungsschnittstelle zum Erfassen einer Dar- 
stellung der Gestaltungsalternative in einem Gestal- 
tungsdarstellungsobjekt. 

6. Objektmodell nach Anspruch 1, mit einer Entschei- 
dungsschnittstelle zum Erfassen einer Entscheidung in 
einem Produktanforderungsobjekt, wobei diese Ent- 
scheidung entweder die Produktidee oder die Gestal- 
tungsalternative hetriflt. 

7. Objektmodell nach Anspruch 1, bei dem Produkti- 
deeobjekt und jedes Gestaltungsalternative-Objekt in 
einer werkzeugneutralen bestandigen Form gespeichert 
werden. 

8. Objektmodell nach Anspruch 2, bei dem Produkti- 
deeobjekt, jedes Gestaltungsalternative-Objekt und je- 
des Produktanforderungsobjekt in einer werkzeugneu- 
tralen bestandigen Form gespeichert werden. 

9. Objektmodell nach Anspruch 5, bei dem Produkti- 
deeobjekt, jedes Gcstaltungsaltcmativc-Objckt und jc- 40 
des Gestaltungsdarstellungsobjekt in einer werkzeug- 
neutralen bestandigen Form gespeichert werden. 

10. Verfahren zum Erfassen von Informationen, die 
produktinnovationsbezogene Daten betreffen, mit den 
folgenden Schritten: 

Erfassen einer Idee fur ein Produkt in einem Produkti- 
deeobjekt, und 

Erfassen einer Vielzahl von Gestaltungsaiternativen fur 
das Produkt in einer Vielzahl von entsprechenden Ge- 
staltungsaiternative-Objekten. 

11. Verfahren nach Anspruch 10, mil dem Schritt des 
Erfassens einer Anforderung fur die Produktidee in ei- 
nem Produktanforderungsobjekt 

12. Verfahren nach Anspruch 11, mit dem Schritt des 
Erfassens eine Funktion zum Erfullen der Produktan- 
forderung in einem Produktfunktionsobjekt 

13. Verfahren nach Anspruch 10, mit dem Schritt des 
Erfassens einer Darstellung der Gestaltungsalternative 
in einem Gestaltungsdarstellungsobjekt. 

14. Verfahren nach Anspruch 10, mit dem Schritt des 
Erfassens einer Entscheidung in einem Entscheidungs- 
objekt, wobei die Entscheidung entweder die Produkti- 
dee oder die Gestaltungsalternative betrifft. 

15. Verfahren nach Anspruch 1, mit dem Schritt des 
Speichems des Produktideeobjekts und jedes Gestal- 
tungsalternative-Objekts in einer werkzeugneutralen 
bestandigen Form. 

16. Verfahren nach Anspruch 10, mit dem Schritt des 
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Speichems des Produktideeobjekts, jedes Gestaltungs- 
alternative-Objekts und des Produktanforderungsob- 
jekts in einer werkzeugneutralen bestandigen Form. 

17. Verfahren nach Anspruch 13, nut dem Schritt des 
Speichems des Produktideeobjekts, jedes Gestaltungs- 
alternative-Objekts und jedes Gestaltungsdarstellungs- 
objekts in einer werkzeugneutralen bestandigen Form. 

18. Computerprogramm mit Programmanweisungeni 
die ein Verfahren zum Erfassen von Informationen, die 
produktinnovationsbezogene Daten betreffen, umset- 
zen, wobei das Verfahren die folgenden Schritte um- 
faBt: 

Erfassen einer Idee fur ein Produkt in einem Produkti- 
deeobjekt, und 

Erfassen einer Vielzahl von Gestaltungsaiternativen fur 
das Produkt in einer Vielzahl von jeweiligen Gestal- 
tungsalternative-Objekten. 

19. Computerprogramm nach Anspruch 18, bei dem 
das Verfahren den Schritt des Speichems des Produkti- 
deeobjekts und jedes Gestaltungsaltemative-Objekts in 
einer werkzeugneutralen bestandigen Form umfaBt. 

20. Computerprogramm nach Anspruch 18, wobei das 
Verfahren die folgenden Schritte umfaBt: 

Erfassen einer Anforderung fur die Produktidee in ei- 
nem Produktanforderungsobjekt, 
Erfassen einer Darstellung der Gestaltungsalternative 
in einem Gestaltungsdarstellungsobjekt, und 
Speichem des Produktideeobjekts, jedes Gestaltungs- 
alternative-Objekts, des Produktanforderungsobjekts 
und jedes Gestaltungsdarstellungsobjekts in einer sepa- 
raten relationalen Datenbank, wobei VerknUpfungen 
zwischen den einzelnen Objekten unter Verwendung 
fremder Schliissel erfafit werden. 
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